Columbia Kermit

home *** CD-ROM | disk | FTP | other *** search

/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000294_news@newsmaster….columbia.edu _Tue Nov 18 10:32:09 1997.msg < prev next >

Wrap

Internet Message Format | 2020-01-01 | 115KB

Return-Path: <news@newsmaster.cc.columbia.edu> Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA29023 for <kermit.misc@watsun.cc.columbia.edu>; Tue, 18 Nov 1997 10:32:09 -0500 (EST) Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA26424 for kermit.misc@watsun; Tue, 18 Nov 1997 10:32:08 -0500 (EST) Path: news.columbia.edu!watsun.cc.columbia.edu!fdc From: fdc@watsun.cc.columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Post FAQ? Date: 18 Nov 1997 15:31:36 GMT Organization: Columbia University Lines: 2325 Message-ID: <64scco$h1q$1@apakabar.cc.columbia.edu> References: <3470B666.11DC@supremecourt.gov> NNTP-Posting-Host: watsun.cc.columbia.edu Xref: news.columbia.edu comp.protocols.kermit.misc:8079 In article <3470B666.11DC@supremecourt.gov>, Roy Buzdor <first.amendment@supremecourt.gov> wrote: : Would it be possible to post the Kermit FAQ on a : monthly, or quarterly basis for those of us who : are fire-wall impaired? : It is rather long, but sure. Here it is: KERMIT: FREQUENTLY ASKED QUESTIONS >From the comp.protocols.kermit.misc newsgroup and elsewhere... Most questions are already answered in the published documentation. Reading the appropriate manuals (in conjunction with online release notes) will get you started, answer most of your questions, and will let you get the most out of your Kermit software: maximize the performance, write scripts to automate your communications tasks, and so on. The Kermit effort is entirely self-supporting, and proceeds from sales of these manuals is our primary source of funding. So please do purchase the manuals. Most recent update: 17 November 1997 Table of Contents 1 HOW TO FIND KERMIT SOFTWARE i 2 WHAT IS THE CURRENT VERSION OF KERMIT? i 3 WHERE TO GET KERMIT MANUALS i 4 WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? (IT ISN'T!) ii 5 MY BACKSPACE KEY DOESN'T WORK! ii 6 HOW DO I USE MS-DOS KERMIT OVER TRUMPET WINSOCK OR MS WfW TCP? iii 7 HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER? iv 8 WHERE IS THE KEY MAP FOR 3270 EMULATION? v 9 HOW CAN I MAKE MS-DOS KERMIT USE COM3, COM4? v 10 MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT. v 11 I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES v 12 BINARY FILES ARE CORRUPTED AFTER TRANSFER v 13 WHY DOESN'T THE HANGUP COMMAND WORK FOR ME? v 14 HOW CAN I MAKE THE DIAL/REDIAL COMMANDS KEEP TRYING? vi 15 I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED. vi 16 HOW DO I WRITE A SCRIPT TO DIAL A PAGER? vi 17 WHEN C-KERMIT DIALS MY V.32BIS (OR V.34) MODEM, I GET THE ERROR vi 'CAN'T CHANGE SPEED TO 14400 (OR 28800)' 18 HOW DO I USE KERMIT WITH PINE? vii 19 HOW DO I GET A SESSION LOG WITHOUT ALL THE EMBEDDED ESCAPE vii SEQUENCES? 20 KERMIT DOESN'T WORK RIGHT WITH MY (RPI) ERROR-CORRECTING MODEM! vii 21 WHAT ABOUT WINMODEMS? viii 22 WHAT KIND OF MODEM SHOULD I BUY? viii 23 MY ARROW KEYS DON'T WORK viii 24 KERMIT UNDER WINDOWS CAN'T FIND MY PORT ix 25 IF I HAVE AN ERROR CORRECTING MODEM WHY DO I NEED KERMIT PROTOCOL? ix 26 HOW DO I USE 'SET KEY' WITH PC F-KEYS, ETC, IN UNIX OR VMS C-KERMIT? x 27 HOW CAN I EXIT FROM C-KERMIT WITHOUT HANGING UP? x 28 WHAT IS SUPERKERMIT? x 29 IS KERMIT SOFTWARE YEAR-2000 COMPLIANT? x 30 IS THERE A KERMIT LIBRARY? x 31 HOW DO I CALL UP A DIALBACK SERVICE? xi 32 HOW DOES THE NUMERIC KEYPAD WORK? xi 33 HOW TO GET RID OF THE "OK TO EXIT?" PROMPT? xi 34 HOW TO TELL KERMIT TO IGNORE DIALTONE? xi 35 WHERE IS THE DIALING SCRIPT FOR MY MODEM? xii 36 I'M HAVING TERMINAL EMULATION PROBLEMS WITH C-KERMIT xii 37 DIVIDE OVERFLOW IN MS-DOS KERMIT xii ------------------------------------------------------------------------------- 1 HOW TO FIND KERMIT SOFTWARE World-Wide Web: http://www.columbia.edu/kermit/ ftp: kermit.columbia.edu This is the definitive source for Kermit software on the Internet. Other Kermit archives or "mirror sites" are not necessarily complete, accurate, or up to date. Newsgroups: comp.protocols.kermit.announce - Moderated comp.protocols.kermit.misc - Unmoderated E-mail: kermit-orders@columbia.edu (Orders and order inquiries) kermit-support@columbia.edu (Tech support) kermit@columbia.edu (General -- not an FTP mail server!) Post: The Kermit Project Columbia University 612 West 115th Street New York NY 10025-7799 USA Fax: +1 212 663-8202 or +1 212 662-6442 ------------------------------------------------------------------------------- 2 WHAT IS THE CURRENT VERSION OF KERMIT? Kermit 95 for Windows 95 and NT: 1.1.15 Sep 30 1997 Kermit 95 for OS/2: 1.1.15 Sep 30 1997 MS-DOS Kermit for DOS and Windows 3.x: 3.15 Sep 15 1997 C-Kermit for UNIX, VMS, AOS/VS, OS-9: 6.0.192 Sep 6 1996 C-Kermit for OS/2 1.x (16-bit: 5A(190) Oct 4 1994 C-Kermit for Stratus VOS: 6.0.192 Mar 7 1997 C-Kermit for Atari ST: 5A(189) Jun 30 1993 Mac Kermit (NOT A REAL RELEASE): 0.993(192) Jun 3 1996 IBM Mainframe Kermit: 4.3.1 Feb 10 1995 Kermit-11 for RT-11: 3.63 Sep 27 1997 Kermit-11 for RSX, RSTS, etc: 3.60 Jun 13 1989 Others (hundreds of them): See kermit/a/aavsys.hlp. Also see the What's New section of our website. ------------------------------------------------------------------------------- 3 WHERE TO GET KERMIT MANUALS MS-DOS Kermit, full-featured communications software for IBM and compatible PCs with DOS or Windows 3.x, is documented in: Christine M. Gianone, Using MS-DOS Kermit, Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN 1-55558-082-3. Packaged with the current version of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 3.5-inch diskette. In computer and book stores, or order direct from Columbia University or from Digital Press. A German-language edition is also available: Christine M. Gianone, MS-DOS Kermit, das universelle Kommunikationsprogramm, Verlag Heinz Heise, Hannover, Germany (1991), 414 pages. Packaged with version 3.12 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 5.25-inch diskette, including German- language help files. Deutsch von Gisbert W. Selke. ISBN 3-88229-006-4. And a French-language edition: Christine M. Gianone, Kermit MS-DOS mode d'emploi, Deuxieme edition, Heinz Schiefer & Cie., Versailles (1993), 406 pages. Packaged with version 3.11 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on a 5.25-inch diskette. Adaption francaise: Jean Dutertre. ISBN 2-901143-20-2. There is also a Japanese book about MS-DOS Kermit, concentrating on the NEC PC9801: Hirofumi Fujii and Fukuko Yuasa, MS-Kermit Nyumon, Computer Today Library 6, Saiensu-Sha Co., Ltd., publishers (1993), 160 pages. ISBN 4-7819-0669-9 C3355 P1854E. C-Kermit 6.0, full-function communication software for UNIX, VMS, AOS/VS, VOS, OS-9, QNX, the Commodore Amiga, and other platforms, is documented in: Frank da Cruz and Christine M. Gianone, Using C-Kermit, Second Edition, Digital Press / Butterworth-Heinemann, Woburn, MA, 1997, 622 pages, ISBN 1-55558-164-1. In computer and book stores, or order direct from Columbia University or from Digital Press. A German-language edition is also available: Frank da Cruz und Christine M. Gianone, C-Kermit--Einfuehrung und Referenz, Verlag Heinz Heise, Hannover, Germany (1994). ISBN 3-88229-023-4. Deutsch von Gisbert W. Selke. The Kermit File transfer protocol is specified in the following book, which also includes tutorials on computers, file systems, data communications, and using Kermit: Frank da Cruz, Kermit, A File Transfer Protocol, Digital Press / Butterworth-Heinemann, Worburn, MA, 1987, 379 pages, ISBN 0-932376-88-6. In computer and book stores, or order direct from Columbia University or from Digital Press. Kermit software for hundreds of different computers and operating systems is available from Columbia University. Contact Columbia for a free Kermit software catalog. ENGLISH-LANGUAGE KERMIT BOOKS: 1. In computer and book stores, or order direct from the publisher, Digital Press / Butterworth-Heinemann with MasterCard, Visa, or American Express: +1 800 366-2665 (Woburn, MA office for USA & Canada, Toll-free M-F 8AM-6PM Eastern time) +1 617 928 2613 (Newton, MA office for sales/marketing info) +44 1865 314627 (Oxford, England distribution centre for +61 03 9245 7111 (Melbourne, Vic, office for Australia & NZ) +65 356-1968 (Singapore office for Malaysia, Singapore, Indonesia, Philippines, Thailand) +27 (31) 2683111 (Durban office for South Africa) 2. From Columbia University: The Kermit Project Columbia University 612 West 115th Street New York NY 10025-7799 USA Tel. +1 212 854-3703 Fax. +1 212 663-8202 E-Mail: kermit@columbia.edu Domestic and overseas orders accepted. Add $10 US PER BOOK for shipping outside of North America. Orders may be paid by MasterCard or Visa, or prepaid by check in US dollars. Add $35 bank fee for checks not drawn on a US bank. Price includes shipping. Do not include sales tax. Quantity discounts are available. Single-copy US prices (in US dollars): Using MS-DOS Kermit . . . . . . . . . . . . . . . . .$ 39.95 Using C-Kermit . . . . . . . . . . . . . . . . . . . .$ 39.95 Kermit, A File Transfer Protocol . . . . . . . . . . .$ 34.95 All three . . . . . . . . . . . . . . . . . . . . . .$ 90.00 GERMAN-LANGUAGE KERMIT BOOKS: MS-DOS Kermit, das universelle Kommunikationsprogramm: DM 79,00 C-Kermit--Einfuhrung und Referenz: . . . . . . . . . . DM 88,00 Verlag Heinz Heise GmbH & Co. KG Helstorfer Strasse 7 D-30625 Hannover, GERMANY Tel. +49 (05 11) 53 52-0 Fax. +49 (05 11) 53 52-1 29 FRENCH: Kermit MS-DOS Mode d'Emploi: . . . . . . . . . . . FF 495,00 Heinz Schiefer & Cie. 45 rue Henri de Regnier F-78000 Versailles, FRANCE Tel. +33 39 53 95 26 Fax. +33 39 02 39 71 JAPANESE: MS-Kermit Nyumon: . . . . . . . . . . . . . . . . . 1,800 Y Saiensu-Sha Co., Ltd. Abe-toku Building 2-4 Kanda-suda cho, Chiyoda-ku Tokyo 101, JAPAN Tel. +81-3-3256-1091 ------------------------------------------------------------------------------- 4 WHY IS KERMIT SO SLOW COMPARED TO ZMODEM? (IT ISN'T!) Path: news.columbia.edu!usenet From: fdc@columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: [HELP] Slow Kermit Transfer ?! Date: 19 Sep 1994 14:15:42 GMT Organization: Columbia University Lines: 153 In article <35jrgsINNdq2@newsman.csu.murdoch.edu.au> anson@csuvax1.csu.murdoch.edu.au (Binh Anson) writes: > I used Kermit 3.13 for my PC, my modem has a speed of 14.4 K, but I > found that the downloading rate from the mainframe to my PC was > still very slow! I tried Telix with SZ (Z-Modem Protocol), and it > was very fast compared to Kermit. Is there a way to accelerate > Kermit transfer ? > Yes. But first, welcome to comp.protocols.kermit.misc. This is the first day of operation of this unmoderated newsgroup. I hope it will prove beneficial to all Kermit users. To answer your question, somewhat longwindedly, since this Question is Asked so Frequently :-) ... Zmodem is optimized for speed on the assumption that it has a clear 8-bit transparent channel with no blockages (small buffers, etc), and so, out of the box, when it works it goes fast. The tradeoff is that it often does not work at all, in which case you have to configure it in various ways -- escaping of control characters, changing window size, etc. In some cases it can't be made to work at all, either because of the nature of the connection, or because of one or both of the computers on the two ends. Kermit, on the other hand, is configured to work -- i.e. transfer files -- out of the box, even under hostile conditions. By default, it does not assume that control characters pass through transparently, nor that large buffers are available. It does not even assume a full-duplex connection. The tradeoff is speed. In a perfect world, there would be no tradeoffs, but the world is far from perfect. 7-bit transmission is still extremely common, small buffers are very common, even in modern terminal servers and other communications processors, flow control is rarely implemented correctly and effectively, telephone lines are still noisy, and we still have a bewildering array of communication methods needed for accessing different kinds of hosts and services. Most PCs are still shipped with non-buffered UARTs; many PCs have interrupt conflicts, noisy buses, etc; many modern modems are buggy. The list goes on. This is by way of demonstrating that Kermit's default tuning is not crazy, and goes a long way towards explaining its justified reputation for dependability. Unfortunately, because of the tradeoffs necessary to achieve its reliability, Kermit has a reputation for slowness: Yes, Kermit transfers are slow if you use the default tuning. However, you can make Kermit go as fast as the communication path will permit by changing a few parameters. But first, here are some general principles that apply to all communications software: 1. Ensure that you have an effective means of flow control enabled at every juncture along the communication path (this applies to any file transfer protocol). For example, when using high-speed, error-correcting modems, you should use some form of hardware flow control, most commonly RTS/CTS. You have to tell the software to use it, AND you have to tell the modem to use it too -- if the flow control methods of the PC and the modem do not agree, then data will be lost. The same is true of the modem at the other end of the connection, and the computer or device it is connected to. 2. If your modem is capable of data compression, use it. Fix the interface speed of the software to four times the connection speed if possible -- e.g. for a V.32bis 14400 bps connection, use an interface speed of 57600, or else the modem's compression capacity is likely to be wasted. 3. On network connections (e.g. TCP/IP), it is usually best to turn off flow control entirely, because the underlying networking method supplies fully effective flow control. Now, to make Kermit go fast, follow these steps: 1. Use real Kermit software, not the many shareware and commercial packages, most of whose Kermit protocol implementations lack the performance features listed below and/or the means for the user to control them. 2. Use long packets. Kermit's default packet length is 94. You can increase it to a theoretical maximum of 9024. Give the following command to the file receiver: SET RECEIVE PACKET-LENGTH 2000 ; (or other length) The longer you make the packets, the more efficient the file transfer will be... IF IT WORKS. If you make packets longer than some buffer somewhere along the line, and effective flow control is lacking, the transfer might not work. Also, the longer the packet, the greater the chance it will be hit by noise, and the longer it takes to retransmit. A good starting value to try is 1000. 3. On full duplex connections, use sliding windows. Sliding windows allow packets to be transmitted in a continuous stream, rather than "stop and wait" style. The command is: SET WINDOW 4 ; (or other number) The maximum is 32 (or less, depending on the implementation). Give this command to both Kermit programs. For text files and uncompressed binary files, this should give you very good performance -- efficiencies in the 85%-100% range. For compressed files, and certain other types of binary files, you can squeeze out another 20-25% efficiency by telling Kermit not to prefix a given list of control characters. A typical sequence might be: SET CONTROL UNPREFIX ALL ; Unprefix all control characters. SET CONTROL PREFIX 0 1 13 129 141 ... ; Add back prefixes for these. This might require some trial and error because there is no way that a communication software program can know what characters are safe and which ones are not on a particular connection. For example, you might be going through an X.25 PAD where Ctrl-P will pop you back to the PAD prompt. Or you might be going through a TELNET terminal server where Ctrl-] or Ctrl-^ will pop you back to the terminal server prompt. Or the connection might be using Xon/Xoff flow control, and sending Ctrl-S as a data character might freeze the connection. If you take all of these steps, using optimal packet lengths, window sizes, and unprefixing, you should achieve transfer rates comparable to, and often better than, the Zmodem implementations that you find in Telix, Procomm, and similar shareware and BBS packages; for example, on a V.32bis/V.42/V.42bis connection, RTS/CTS flow control, no parity, 57600 bps interface speed: Typical text files: 3500 cps (characters per second) Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE) Compressed files: 1600 cps (e.g. ZIP files) These figures come from Kermit News #5, June 1993, which is available on the Web and also via anonymous ftp from kermit.columbia.edu, directory kermit/e, file newsn5.txt (ASCII) or newsn5.ps (PostScript). Also see Kermit News #4, newsn4.txt (.ps), for a detailed discussion of long packets and sliding windows. [As of late March 1995, there are also html versions of these files suitable for Web access.] Kermit software is available via anonymous ftp to kermit.columbia.edu [128.59.39.2], directory kermit and its subdirectories. There are literally hundreds of different Kermit programs for *almost* every machine and operating system imaginable. The most widely used Kermit programs are: - MS-DOS Kermit for DOS and Windows 3.x. No, this is not a native Windows application, but yes, this is the Kermit software we recommend and support for Windows 3.x. File: kermit/archives/msvibm.zip - C-Kermit for UNIX, VMS, OS-9, AOS/VS, the Commodore Amiga, etc. - IBM Mainframe Kermit-370 for VM/CMS, MVS/TSO, CICS, and MUSIC. kermit/b/ik*.*. - Frank POSTSCRIPT: The Kermit software for Windows 95 and NT is Kermit 95. It was first released in October 1995 (after this message was posted). ------------------------------------------------------------------------------- 5 MY BACKSPACE KEY DOESN'T WORK! From: fdc@columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: [?] Backspace key says, "^?" Date: 7 Jan 1995 21:26:44 GMT Organization: Columbia University Lines: 122 In article <D201pG.DMB@indirect.com>, Jim Monty <monty@indirect.com> wrote: > DISCLAIMER: I've looked for the answer to the following question in > _Using MS-DOS Kermit_ and in the documentation included with MS-DOS > Kermit 3.13. I either couldn't find the answer or didn't understand > it if I did. > Thank you for consulting the documentation. > I'm using MS-DOS Kermit 3.13 on an i80386SX machine running MS-DOS > 6.0, using a 14,400 bps Zoom VFP V.32bis modem. Kermit is set for > VT220 terminal emulation and is using the Latin1 character set and > code page CP437. I've not mucked with much in the initialization > files, so you may assume that any other parameters are still set to > the "factory" defaults. > > Alas, the question: In some online environments, my backspace key > behaves as one would expect it to. In others, hitting the backspace > key results in either (1) nothing happening, or (2) the characters > "^?" appearing on the screen. > Or (3) the Backspace key acts like an Interrupt character on the host (this usually happens with System V based UNIXes). > I can, however, use Ctrl-H in these > situations. In these exact same online environments (e.g., vi > insert mode when connected to my dial-up UNIX shell account) under > analagous circumstances, the other terminal emulator that I use, > Telemate Version 3.12, does not behave this way. The backspace key > functions as a destructive backspace. > > I presume that the change I need to make to my MS-DOS Kermit > configuration is a simple one, but I can't figure it out. And I've > never really wanted to bother to spend a lot of time trying to > figure it out myself. (I want the magic straight from the wizards' > minds.) Thanks, in advance, for taking the time to help me. > > Jim Monty, Kermit Cheerleader at Arthur Andersen LLP > Well, Jim, I think it's finally time to classify this as a Frequently Asked Question and add it to the FAQ (kermit.columbia.edu:kermit/FAQ.TXT). As you have discovered, different hosts and applications use different characters (or sequences) for destructive backspace. The terminal emulator, Kermit or otherwise (including Telemate -- if its backspace key works for you in all circumstances, I think that's just a stroke of luck), has no way of knowing what host or application you are using, and therefore no way of knowing what to send when you press the Backspace key. Of course, Kermit's Backspace key must send *something* "out of the box", so it uses one of the several most likely destructive backspace values, and in fact the one that is defined in ASCII to be destructive backspace, namely Rubout, also known as Delete or DEL, character number 127, which sometimes is displayed as "^?". Lest anyone believe this is a frivolous choice, I quote from American National Standard X3.4-1977, Section 5.1, Control Characters: 0/8 BS (Backspace). A one-active-position format effector that moves the position backward on the same line. 7/15 (DEL). A character used primarily to erase or obliterate an erroneous or unwanted character... In cases where the default does not work, Kermit lets you redefine the Backspace key (or any other key) to send whatever you want it to send (or to take any other actions) with the SET KEY command. The SET KEY command has two operands: a unique identifier for a key or key combination, called a scan code, and the value or action to be assigned to the key. Scan codes are written with a preceding backslash (\). The scan code for the Backspace key is \270. The default definition for this key is \127, meaning the character whose numeric value is 127, i.e. DEL. You can find out a key's scan code by consulting Table I-9 in the manual (pages 285-288), or by giving the SHOW KEY command to Kermit and then pressing the desired key or key combination. Now, as you have discovered, some applications use Ctrl-H -- ASCII BS (Backspace) -- for destructive backspace. Consulting the ASCII table on page 275, you see that the ASCII code for BS is 8. So to make PC's Backspace key send BS instead of DEL, give this command: SET KEY \270 \8 If you use Kermit only to connect to hosts and services that use BS for destructive backspace, then you can put this command in your MSCUSTOM.INI file, and it will take effect automatically every time you start Kermit. But some people (like yourself) switch between different hosts and/or services that expect different characters or sequences for destructive backspace. You can, of course, give Kermit the appropriate command every time you switch from one to another: SET KEY \270 \8 ; Backspace sends BS or: SET KEY \270 \127 ; Backspace sends DEL or you can use the macros that are already defined in MSKERMIT.INI for this. In version 3.14, for example, we have macros with names like VAX and IBM. The VAX macro sets things up (including the Backspace key) for communicating with VAXes and VAX-like systems, and that means, among other things, setting the Backspace key to send DEL. The IBM macro, on the other hand, is used for communicating with IBM mainframes in linemode, where BS is used. You can use these macros as they are, or you can write your own macros based upon them and add them to your MSCUSTOM.INI file. To use a macro, just type its name at the MS-Kermit> prompt. Suppose, for example, you normally access two different systems: a BBS (which uses 8-bit characters, ANSI terminal emulation, and BS) and a UNIX system (which uses 7-bit characters, VT220 emulation, and DEL), and these items need to be changed when you switch between the two. You could write two macros such as these: define bbs set term byte 8, set term type ANSI, set key \270 \8 define unix set term byte 7, set term type vt220, set key \270 \127 And then each time you want to use the BBS, you just type "bbs" at the MS-Kermit> prompt, and each time you want to access the UNIX system, you type "unix". Of course, you could take this process even further, and turn the BBS and UNIX macros into complete connection-establishment and login scripts, following the directions in Chapter 14 of the manual, on script programming. - Frank ------------------------------------------------------------------------------- 6 HOW DO I USE MS-DOS KERMIT OVER TRUMPET WINSOCK OR MS WfW TCP? Date: Sun, 8 Jan 95 13:27 EST To: .... From: kermit@columbia.edu Subject: Re: Using Kermit with Trumpt Winsock > I have an internet connection (SLIP) using Trumpet Winsock to > establish the connection to the server under windows. I'd like to > use kermit at that point to telnet to my company's computer. I've > filled in the IP addresses in my custom file, but when I run kermit, > and try to telnet, I get the message: > > Cannot attach to an Ethernet Packet Driver.... > > Can you give me an idea of what I'm doing wrong? > The rule for DOS, Windows, and similar PC operating systems is: ONE APPLICATION PER PROTOCOL PER NETWORK BOARD This applies also to serial ports being used as if they were network boards, e.g. via SLIP. If you are talking about Windows 95 or Windows NT, you can use Kermit 95, which does use Winsock -- any 32-bit Winsock stack (Microsoft, FTP Software, or Trumpet). If you are talking about Windows 3.x, read on. Now, Trumpet Winsock is using (i.e. registered for) the TCP protocol on your "network board". Thus, when you try to activate Kermit's own built-in TCP/IP networking, it finds that it can't register TCP because TCP is already registered. Thus it "Cannot attach to ... Packet Driver". One might think it would be possible, then, to tell Kermit to "use" Winsock. But Winsock TCP/IP stacks are strictly for pure Windows (and NT) programs, not for DOS programs. MS-DOS Kermit is a "Windows-aware" DOS program, but a DOS program nevertheless; it runs from the DOS prompt and within DOS emulator boxes in various operating systems, and cannot access Winsock. If you want to make a TCP/IP connection with MS-DOS Kermit when Winsock is running, you have to unload Winsock and use Kermit's own built-in TCP/IP capability directly over an Ethernet- or SLIP-class packet driver or an ODI driver. Or else install a second network adapter. Or... It is PERHAPS POSSIBLE, but not necessarily recommended, to run Kermit's TCP/IP stack alongside of Winsock using Dan Lanciani's NDIS3PKT shim, or to use the PKTMUX TCP/IP multiplexor. Use these methods at your own risk. NDIS3PKT, in Dan's words: "Ndis3pkt is a Windows virtual device (VxD) that provides multiple emulated packet driver interfaces in Windows VMs and converts to NDIS3. It knows how to route packets to the correct VM at upcall time (similar to the function of WINPKT) and it includes an optional tcp multiplexor to allow multiple tcp/ip stacks to coexist with the same IP address (similar to the function of PKTMUX). It can also support multiple boards, but that isn't a much-used feature. It can also emulate a class 1 (Ethernet) packet driver on top of Token Ring. In other words, ndis3pkt is intended to be a one-stop solution to packet driver applications over NDIS3. "Now, when people talk about ``Winsock'' they often mean one of the Winsock providing packages that runs in the Windows system VM, e.g., Trumpet. Because Trumpet Winsock is really just another packet driver application, ndi3pkt is perfectly happy to multiplex it along with any number of DOS applications. Thus, from a high-level viewpoint, users see this as sharing DOS applications with Winsock. In reality, ndis3pkt knows nothing about Winsock, but the net effect is the same." NDIS3PKT is in pub/ndis3pkt on newdev.harvard.edu, available by by anonymous ftp. Be sure to read the license in the accompanying README file, and be sure you have a version dated 17 Mar 95 or later. NOTE: As of January 1997, this location has moved to: ftp://hsdndev.harvard.edu/pub/ndis3pkt http://ndtl.harvard.edu/ndis3pkt/ (Later, August 1995, more from Dan): "Some people have been able to run kermit & MSTCP32 w/WfWG 3.11 together using my ndis3pkt.386 driver. The trick is to use different IP addresses for MSTCP32 and kermit. More generally, you need one IP address for MSTCP32 and one IP address for all your other packet-driver applications. This is because, although ndis3pkt includes a tcp session multiplexor that allows multiple packet-driver-based tcp/ip stacks to share the same IP address on one machine, ndis3pkt has no control over the MSTCP32 stack. If you try to use the same address for both, MSTCP32 will reset kermit's connections and such. "Some people have been unable to get the MSTCP32+kermit+ndis3pkt combination to work in configurations that appear superficially identical to those which work elsewhere. I suspect there is some minor detail of interest to be found here, but I don't know what it is. :)" For additional details, see discussions in comp.protocols.tcp-ip.ibmpc and in the ndis3pkt documentation. PKTMUX, also a risky proposition, is nevertheless, reportedly used with success at some sites. As one user reports, "I would not dismiss the use of a packet driver, PKTMUX and as many PKTDRV stubs as you need. We use that setup with TCP/IP Kermit, NCSA Telnet and winsock compliant apps. If you also use QEMM, none of that takes ANY low memory and it is stable." ------------------------------------------------------------------------------- 7 HOW TO TRANSFER FILES THROUGH A 3270 PROTOCOL CONVERTER? From: fdc@columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: Kermit File Transfer and tn3270 Date: 16 Jan 1995 16:46:18 GMT Organization: Columbia University Lines: 169 In article <173276AEB.BDESIMON@uga.cc.uga.edu>, Bert DeSimone <BDESIMON@UGA.CC.UGA.EDU> wrote: > Gotta figure this has come up before. We are evaluating a terminal > server that supports tn3270. No problem using MS-Kermit to connect > to the terminal server and connect via tn3270 to an IBM mainframe. > However, file transfers (either invoking server on the mainframe or > not) always fail. Connecting through this same terminal server to > the same mainframe through a 7171 presents *no* problem with file > transfer. (BTW: I don't have to be using tn3270 on a terminal > server; file transfers with Kermit using tn3270 on a Unix host fail > the same way). > > I am speculating that the mainframe Kermit must send a transparent > mode sequence, ordinarily processed by the protocol converter, that > is causing the problem. > One of the major strengths of the Kermit protocol is its ability to transfer files with IBM mainframes over a wide variety of connection types, and there is an excellent Kermit software program for the IBM mainframe, which is available for VM/CMS, MVS/TSO (and ROSCOE), CICS, and MUSIC. The current version is 4.3.1, with version 4.3.2 in beta test. All of the Kermit books and manuals ("Kermit, A File Transfer Protocol", "Using MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit online manuals) describe the process(es) in some detail. Here is a brief summary. Half-duplex (local-echo), line-at-a-time connections are generally handled by the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which performs the following protocol-related settings: set local-echo on set parity mark set flow none set handshake xon Full-screen sessions go through a 3270 terminal emulator. This can reside anywhere between the client software (such as MS-DOS Kermit) and the mainframe. For the past 10 or 20 years, the most common place to find the 3270 emulator was on a special purpose "protocol converter": a box that has serial lines on one side and a connection to the mainframe on the other. This box generally works by tricking the mainframe into thinking it is a "control unit" with multiple 3270 terminals attached, and at the same time tricking the terminals into thinking they are communicating with a "normal" ASCII character-at-a-time host. The box converts between 3270 data streams and ASCII terminal (e.g. VT100) conventions. This includes ASCII/EBCDIC character-set conversion, cursor positioning and screen painting, and keystroke interpretation. As you can imagine, all of these conversions would normally have a disastrous effect on Kermit protocol packets, and also upon any other type of data that has to be transmitted "as is", without conversion, such as graphics terminal directives. Thus, many protocol converters support a "transparent mode", that allows the mainframe host to command them to turn off their conversion functions, and at a later time, turn them back on. When everything works as planned, the only Kermit commands required for going through the protocol converter are: set flow xon/xoff ; (usually) set parity even ; (or other) Everything else corresponds to the normal Kermit defaults (remote echo, no "handshake", etc). Unfortunately, the method for entering and leaving transparent mode differs from one 3270 emulation product to another. Ideally, there are two components: (1) the identification phase, in which the mainframe software issues a special instruction that causes the protcol converter to respond in a unique (but harmless) way; and (2) the actual enter- and exit-transparent-mode directives. IBM Mainframe Kermit needs to know which kind of transparency, if any, is used by the protocol converter so it can be put into transparent mode at the beginning of packet protocol and taken out of it upon return to interactive command mode. There are several ways that mainframe Kermit can go about this. First, you can use the SET CONTROLLER command to tell it which style of transparency is used by the protocol converter. Second, mainframe Kermit can be set up by the system administrator to always use a particular style. Third, it can attempt to "autodiscover" the controller type by issuing various types of identification queries and checking the results. The third method is not very reliable, however, since many types of protocol converters fail to respond to these queries even when they do implement a particular style of transparency. Nowadays, special-purpose protocol converters are giving way to general purpose terminal and compute servers that include a "tn3270" function. tn3270 is a special kind of TELNET program that also performs 3270 emulation, and requires that the mainframe be on a TCP/IP network and have a TN3270 server. Here are some examples: 1. UNIX tn3270. Most UNIX systems come with a tn3270 program that lets you make a full-screen connection to an IBM mainframe. Once you have made the connection, you should be able to start Kermit on the mainframe, give it a SEND, RECEIVE, or SERVER command, escape back to your terminal emulator (e.g. MS-DOS Kermit), and transfer files without any special settings. If you have trouble with this, then: - Ask mainframe Kermit to "show controller". If it doesn't say Series/1, then tell it to "set controller series1". - Try using shorter packets. The maximum length that can pass through the protocol converter might be less than what you are trying to use. A typical maximum value might be 1700. - Tell one or both Kermit programs to "set parity space". 2. VMS tn3270. Depends on the TCP/IP version. TGV Multinet, for example, does not claim to support transparent mode. 3. Cisco terminal server tn3270. Current releases of Cisco terminal server software include a tn3270 feature that is supposed to permit Kermit transfers, but it has bugs. Sometimes these bugs can be worked around by using the methods listed in (1) above and specifying VERY short packets, like 30 or 40 bytes. Sometimes they can't be worked around at all. A future release of Cisco software (probably 10.3) will include new tn3270 software that implements Series/1-style transparency correctly, and allows Kermit transfers of both text and binary files in both directions using packet lengths up to about 1900 (or whatever the total screen size is). If you try all of these workarounds with your terminal server and still get failed transfers, make packet logs and/or debug logs in both Kermit programs to find out what the terminal server is delivering to each Kermit program, and report the misbehavior to your terminal server vendor. For further information about specific protocol converters and how to configure IBM Mainframe Kermit for them, please read the ik0aaa.hlp file that comes with IBM Mainframe Kermit. Finally, it is possible to transfer files through a 3270 fullscreen connection even when 3270 emulator can't be put into transparent mode at all. You can read about this in the second edition of Using C-Kermit and the MS-DOS Kermit update notes file (KERMIT.UPD). Quoting from the latter: "Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes through 3270 protocol converters that do NOT support transparent mode, to be used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN command on VM/CMS, MVS/TSO, or CICS. MS-DOS Kermit 3.13 or later and IBM Mainframe Kermit 4.2.3 or later required. Commands: SET PARITY EVEN ; Or whatever SET FLOW XON/XOFF ; Or whatever SET SEND START 62 ; Greater-than sign SET RECEIVE START 62 ; Ditto SET BLOCK BLANK-FREE-2 ; New block-check type SET HANDSHAKE NONE BLANK-FREE-2 is a new block-check type, exactly like type 2, except encoded to never contains blanks. Give IBM Mainframe Kermit the following commands: SET CONTROLLER FULL SET SEND START 62 SET RECEIVE START 62 SET BLOCK BLANK-FREE-2 SET HANDSHAKE 0 Doomsday Kermit file transfers are not as reliable as regular Kermit protocol transfers, and they are much slower. Use this method only as a last resort; that is, only when you can't get a transparent-mode fullscreen connection or a linemode connection to the mainframe. (end quote) And beyond finally: in the future, we expect to add 3270 emulation to the Kermit software itself, so you will be able to make tn3270 connections directly from Kermit to the mainframe without having to go through a "black box" for the conversion. Of course, Kermit software will handle transparency correctly (and automatically). (And no, I can't estimate when built-in 3270 emulation will be available.) - Frank ------------------------------------------------------------------------------- 8 WHERE IS THE KEY MAP FOR 3270 EMULATION? Real 3270 terminals have all sorts of keys that regular ASCII terminals (and PCs and Macintoshes and UNIX workstations, etc) do not have. A big part of the job of a 3270 protocol converter is to convert between ASCII keystrokes (including escape sequences) and 3270 keys such as PA1 through PA3 and PF1 through PF24. The administrator of the 3270 protocol converter creates the mapping. So in order to make a 3270 key map for Kermit, you first have to find out what the mapping in the protocol converter is, and then assign the ASCII values (characters or sequences) that correspond to each 3270 key to the desired PC (or Mac, etc) key. It is the responsibility of each site administrator to document the key mappings used by its protocol converters. Once you know the ASCII values that correspond to each 3270 key, then it's easy to create Kermit key bindings. For example, suppose the 3270 "cursor left" function (left arrow) is mapped to ASCII Ctrl-B (ASCII character 2). Then in MS-DOS Kermit you would: SET KEY \4427 \2 where \4427 is the scan code of the PC's (gray) left arrow key, and \2 is the code for the ASCII value of the Ctrl-B character. ------------------------------------------------------------------------------- 9 HOW CAN I MAKE MS-DOS KERMIT USE COM3, COM4? From: fdc@columbia.edu (Frank da Cruz) Newsgroups: comp.protocols.kermit.misc Subject: Re: COM3 available in 3.14? Date: 20 Jan 1995 15:48:20 GMT Organization: Columbia University In article <1995Jan19.232004.8689@midway.uchicago.edu>, Cal Lott <cal@gsbux1.uchicago.edu> wrote: > I was simply wondering if version 3.14 (or any earlier) could > address COM3 and above. > A frequently asked question. The short answer: Yes. The medium answer: COM3 and above have no standard address or IRQ, hence communications software (Kermit or anything else) can't always find them, in which case you have to specify the address and IRQ, using a sequence like: SET COM3 \x3e8 5 SET PORT COM3 (You need both commands, in the order shown.) You must also beware of "missing" COM ports. To use (say) an internal modem as COM4 when there is no COM3 is not straightforward. The long answer: Read section 6 of the KERMIT.BWR file on your MS-DOS Kermit 3.14 diskette (the version at kermit.columbia.edu in kermit/a, file mskerm.bwr, might be newer). - Frank ------------------------------------------------------------------------------- 10 MS-DOS KERMIT PATCHES DON'T SEEM TO TAKE EFFECT. Since the release of MS-DOS Kermit 3.14, there have been persistent reports that patches don't seem to "stick". That is, after giving a PATCH command, the patch level is still reported as 0. This can happen if the patch file is transferred to the PC from a UNIX system in binary mode, so the lines end with LF rather than CRLF -- DOS does not recognize the line boundaries and therefore Kermit does not see valid patches. Cure: make sure each line ends with CRLF. Fix it in an editor, or re-transfer the file in text mode. Also, remember there is no longer a need to rename the patch file to MSKERMIT.PCH. Since there are now three different Kermit executables, there must be three corresponding patch files. For version 3.14, these are: MSR314.PCH -- For full-featured KERMIT.EXE MSRM314.PCH -- For "medium-size" KERMITE.EXE MSRL314.PCH -- For "Kermit Lite" KERLITE.EXE Notice that each patch file includes the version number as part of its name. This allows you to run different versions of Kermit without confusion about patching. ------------------------------------------------------------------------------- 11 I CAN TRANSFER TEXT FILES BUT NOT BINARY FILES Here are the causes (and cures) listed in decreasing order of likelihood: 1. You are going through a terminal server or other type of connection (telnet, rlogin, etc) that chops off the 8th bit. Kermit can't tell that this is happening (as it can with devices that add even, odd, or mark parity), so you have to tell it. The command is: SET PARITY SPACE 2. You have used the SET CONTROL CONTROL UNPREFIX command to unprefix one or more control characters that are not safe. Tell Kermit to: SET CONTROL PREFIX ALL and see if it works. If so, you'll have to home in on the offender(s). ------------------------------------------------------------------------------- 12 BINARY FILES ARE CORRUPTED AFTER TRANSFER Some non-Columbia Kermit implementations simply do not work, including some found in BBS software. For example, if you download a file from a BBS using their Kermit protocol option and find a lot of Ctrl-Ys in your file where only actual letter Y's should be, then the BBS has a broken Kermit implementation. The same is also true if a file downloaded from a BBS in binary mode is bigger than the original. Ask your BBS sysop to install MS-DOS Kermit ("Kermit Lite") as an external protocol. See the KERMIT.UPD file in the MS-DOS Kermit 3.14 distribution for additional information. The more common cause, however, for "corrupted" binary files is that they were transfered in text mode. Both Kermit and ftp transfer files in text mode by default. This means that record formats and character sets are likely to be converted. You can tell Kermit to skip all conversions and transfer the file literally, as-is, with the command: SET FILE TYPE BINARY Normally, it is sufficient to give this command to the FILE SENDER before giving it the SEND command. But there are some exceptions to this rule: 1. One or both Kermits do not support "Attribute packets" (or they are disabled). This is true of many of the commercial and shareware Kermit implementations. Cure: tell BOTH Kermits to use binary mode. 2. You are using some combination of C-Kermit 5A(190) or later, MS-DOS Kermit 3.14 or later, or IBM Mainframe Kermit 4.3.1 or later in client server mode. In this case, it is the CLIENT's file type setting, rather than the file sender's, that prevails. Cure: tell the CLIENT to SET FILE TYPE BINARY, or to be extra sure, tell them both. 3. You are sending the file from VMS C-Kermit, which is unique among Kermit programs in its ability to automatically switch between text and binary mode based on the file's characteristics. VMS C-Kermit ignores SET FILE TYPE BINARY and SET FILE TYPE TEXT when sending files, and instead uses binary mode if the file's record format is Fixed, and text mode otherwise. However, some binary files, notably VMS ZIP files, are stored using a "text-style" record format (Stream_LF), so Kermit sends them in text mode. You can override this by telling it to SET FILE TYPE IMAGE. If you follow all these directions and binary transfers still come out wrong, then perhaps the file you were downloading was corrupt to begin with -- e.g. it was ftp'd in text mode instead of binary mode. ------------------------------------------------------------------------------- 13 WHY DOESN'T THE HANGUP COMMAND WORK FOR ME? On network connections, Kermit's HANGUP command executes the appropriate network protocol for closing the connection, and this should always work. On serial connections, the HANGUP commands turns off the computer's DTR (Data Terminal Ready) signal for a period of time. According to the standard that governs modem signals, this action is supposed to make a modem hang up the phone call. If it doesn't: 1. Your modem has been configured to "Ignore DTR". This setting is available on most Hayes-compatible modems, either on a physical switch (such as Configuration Switch 1 on the Hayes 1200) or as a command (&Dx on Hayes 2400 and later, and compatibles). In many cases, "Ignore DTR" is the factory setting. If you want your modem to obey the DTR signal, then you should set the switch appropriately, or give the command AT&D2. The actual syntax of the command might vary among different brands and models of modems, so consult your modem manual for details. 2. Your cable or connector has DTR "hotwired high", meaning that the DTR wire is jumpered to some other signal that is always high (on). If this is not what you desire, you should replace your cable with a standard modem cable. 3. You are using a Macintosh with a "hardware handshaking cable". This is actually the same situation as (2), except there is no way to "fix" the cable - please read the ckmker.bwr file for an explanation. To work around these problems in Kermit, without actually fixing the underlying cause, you can use a macro that escapes back to the modem's command processor and gives it the command to hang up. Such a macro is predefined for you in the MS-DOS Kermit 3.14 initialization file, MSKERMIT.INI: ; ATHANGUP macro. Use this if regular HANGUP command doesn't do the trick. def ATHANGUP sleep 1,out +++,sleep 1,out ath0\13 (Note: C-Kermit uses this technique anyway.) In MS-DOS Kermit, you can assign execution of this macro to the "hot key" of your choice, for example: set key \315 {\Kathangup} ; Assign ATHANGUP macro to the F1 key In Mac Kermit, you can just go to the terminal screen and do it by hand: - Pause at least one second - Type +++ - Pause at least one second - Type ATH0 (letters A, T, H, digit zero) - Press the return key. The modem should hang up and say NO CARRIER. ------------------------------------------------------------------------------- 14 HOW CAN I MAKE THE DIAL/REDIAL COMMANDS KEEP TRYING? In Kermit 95, just click on the appropriate boxes in the graphical Dialer (Options -> Dialing -> Procedures), or use the following commands at the command prompt: K-95> set dial retries 30 (How many times to redial) K-95> set dial interval 20 (How long to wait between tries) K-95> dial 5551212 In C-Kermit 6.0, use the "set dial retries" and "set dial interval" commands shown above. In MS-DOS Kermit, the DIAL command is defined in the MSKERMIT.INI file, and it does indeed retry the call several times. REDIAL is also a macro, which simply invokes the DIAL macro with the number most recently dialed; hence it, too, tries the number several times. If you want to change the number of times that the DIAL macro tries, or the conditions under which it retries, or the interval between tries, simply edit the DIAL macro definition in MSKERMIT.INI. ------------------------------------------------------------------------------- 15 I ENABLED SLIDING WINDOWS BUT IT LOOKS LIKE ONLY ONE IS USED. Newsgroups: comp.protocols.kermit.misc Subject: Re: Sliding windows - only one is used? Date: Wed Feb 15 09:21:08 1995 From: fdc@columbia.edu (Frank da Cruz) In article <3hn07m$4dl@israel-info.datasrv.co.il>, 4th Dimension <winter@zeus.datasrv.co.il> wrote: > I'm using MS-Kermit 3.14, PL3 on my PC, talking to C-Kermit 5A(190) > on the remote Sun. When I start MSK, I load the FAST macro to get > maximum thruput. Transfer of data is pretty fast, except that I > never see more than one window used out of the three. Is this a > bug, a feature, or am I doing something wrong? > It's not a bug and you are probably not doing anything wrong. When two Kermit programs have agreed to use a maximum window size greater than one, let's say 4, here is what happens: The FILE SENDER can send up to 4 packets without waiting for an acknowledgement from the file receiver. Each unacknowledged packet sits in the file sender's window until it is acknowledged. Thus its window size grows from 1 to 2 to 3 to 4. If acknowledgments arrive quickly, the window might not grow to its maximum size because it does not need to. The job of the FILE RECEIVER is to accept and verify packets, decode them, and write the decoded contents out to the file. If packets arrive in sequence, then each one is processed and disposed of as soon as it arrives. If, however, a packet arrives that has a sequence number that is more than one greater than the previous packet that was successfully processed, this means that a packet is missing. Thus the packet that just arrived can't be written out to disk because if it were, the file would have a piece missing. So the out-of-sequence packet is stored in the receiver's window until the missing piece is filled in. Thus you won't see the file receiver's window size exceed one unless there have been transmission errors, no matter what window size the file sender might be using. For greater detail see pages 102-103 of "Using MS-DOS Kermit" or pages 158-161 of "Using C-Kermit" (1st edition) or pages 256-260 of the second edition. - Frank ------------------------------------------------------------------------------- 16 HOW DO I WRITE A SCRIPT TO DIAL A PAGER? A numeric pager is one that can display a number -- usually the number to be called back. The number is entered by pressing Touch-Tone keys on your telephone, usually terminated by pressing the "#" or "*" key. Numeric pagers are not modems. Therefore when you dial one, it does not return a carrier signal. Therefore, the dialing modem will not say "CONNECT" or turn on its carrier signal. Therefore, DIAL commands will not succeed. You can type commands to your modem manually for testing. For example: ATDT7654321,,,,,8765432#; In this example we Tone-dial the phone number "7654321", then we pause for ten seconds (",,,,,") to give the pager time to answer the call, then we send "8765432" to be displayed on the pager, then we send the "#" tone, and then we return to command mode (";"). The modem should respond "OK". The details will vary with your modem, your telephone service, and the pager you are dialing. Let's assume we have a Hayes 2400 or higher compatible modem. Here's a sample command file to call a numeric pager: define \%a 7654321 ; Number to call define \%b 8765432 ; Number to display on pager set port xxxxxxx ; Select the communication device set speed 2400 ; Any speed supported by the modem output AT\13 ; Make sure it's in command mode input 3 OK ; ... if fail stop 1 Can't get your modem's attention output {ATDT\%a,,,,,\%b#;\13} ; Make the call input 3 OK ; ... if fail stop 1 Can't place call You can turn this into a macro that accepts the numbers as arguments. See "Using MS-DOS Kermit" or "Using C-Kermit" for additional script programming instructions, and your modem manual and the pager manual for details of calling and paging. Note: the OUTPUT string is enclosed in curly braces to force the commas to be taken literally (if you were using this command in a macro definition and did not enclose the OUTPUT string in braces, the commas would be command separators). Note #2 - Some modems might also support a "wait for quiet answer" feature, e.g. by using the at-sign "@" in the dialing string: ATDT7654321@8765432#; What about alphanumeric pagers? You have to dial the paging service and then either go through a series of prompts, or else execute a protocol like TAP. C-Kermit 6.0 comes with a TAP paging procedure, ckepage.ksc. You can also send an alpha page "by hand". The manual method goes like this (at least for paging services that use TAP "manual mode"): 1. Set up the call. 2. Make sure that DIAL succeeds (Alpha pagers, unlike numeric pagers, will send carrier back). 3. Look for "ID=". 4. Send uppercase "M" followed by carriage return. 5. You are prompted for the destination pager ID. Send it, followed by a carriage return. 6. You are prompted for the text of the message. Send the text. It might be restricted to one line, and even if not, it might be restricted to a certain total length. 7. You might be prompted in some way for more pages or lines; you can answer yes or no. 8. Assuming you answer no, optionally look for the farewell message, then hang up. The exact procedure and prompts vary according to the paging service, so you'll need to go through the process manually to see exactly what the prompts and sequences are. Then you can write a Kermit script to send manual-mode alphanumeric pages automatically. ------------------------------------------------------------------------------- 17 WHEN C-KERMIT DIALS MY V.32BIS (OR V.34) MODEM, I GET THE ERROR 'CAN'T CHANGE SPEED TO 14400 (OR 28800)' Dialing is covered in detail in Using C-Kermit, second edition, and the problem listed in the title of this section should occur only rarely in C-Kermit 6.0 (it was quite common in earlier versions). To recapitulate very briefly: older modems, like the Hayes 1200 and 2400, that did not do error correction or compression, but that could negotiate their modulation speed, would report the modulation speed upon successful connection, and change their interface speed to match. Thus, the communication software would also have to change its own interface speed, or else the user would see only garbage. Modern modems have two different speeds: the interface speed and the modulation speed. The interface speed can be kept constant even though the modulation speed changes. Or not, depending on how the modem is configured. C-Kermit versions prior to 6.0 had no way of knowing whether your modem is set up to lock its interface speed, or to change it to match the modulation speed, and therefore no way of knowing whether to believe the "CONNECT 28800" (or whatever) message. By default, for compatibility with the huge installed base of older modems, it did believe, and therefore changed its interface speed according to the CONNECT message. But if your modem's interface speed is locked (which it SHOULD be if it is an error-correcting, data-compressing modem), you must tell Kermit NOT to change its interface speed by giving it the command: SET DIAL SPEED-MATCHING OFF Now to complicate matters, some of the newer modulations report speeds that are not commonly supported by the host operating system, such as 14400 and 28800. Hence the message "Can't change speed to 14400" (or 28800). But even if these speeds were supported, you would not want Kermit changing to them if the modem's interface speed was locked. You would still see only garbage, but you would not get the "Can't change speed" message. C-Kermit 6.0, by contrast, has a much more comprehensive modem database, and automatically chooses the appropriate SPEED-MATCHING and other parameters when you choose your modem type. Therefore, when you choose a high-speed modem type, one that is capable of speed buffering, C-Kermit automatically set DIAL SPEED-MATCHING to OFF; whereas if you choose (say) the Hayes 2400 modem type, it will set it ON. You can override these automatic choices by giving explicit SET MODEM and/or SET DIAL commands after your SET MODEM TYPE command. See "Using C-Kermit" for additional detail. ------------------------------------------------------------------------------- 18 HOW DO I USE KERMIT WITH PINE? Here's a tip sheet we use at Columbia University - thanks to Joe Brennan. SCREEN FORMATTING Make sure that your UNIX terminal type agrees with Kermit's terminal emulation. For example, if Kermit is emulating a VT320, tell UNIX: export TERM=vt320 or: setenv TERM vt320 If there is a complaint about "terminal type unknown" when starting Pine, then try a lesser VT terminal model, such as VT220, VT102, VT100. PRINTING Pine's print command, letter Y, is known to work with MS-DOS Kermit and Mac Kermit. With MS-DOS Kermit, if the printer is directly attached, it should make the printer print the selected email message. With Mac Kermit, it should send the selected email message into the printer buffer, which can be seen in the Printer window, and which can be printed using the print command in the pulldown File menu. The command ''pcprint'' on UNIX (*), which prints any text file, does the same thing as Pine's Print command. It may be easier to debug problems by running a command like ''pcprint .profile'' at the UNIX shell ($ prompt). (*) pcprint is a UNIX shell script: ---(cut here)--- echo -n '<ESC>[5i' if [ $# -eq 0 ]; then cat else cat $* fi echo -n '<ESC>[4i' ---(cut here)--- (Replace <ESC> by a real Escape (ASCII 27) character. DOWNLOADING FROM PINE TO THE PC Use Pine's command letter E, Export, to copy a message into a file. This file will be created in your home directory on UNIX. Then it can be downloaded to your PC or Mac using Kermit. After you finish, remember to remove the now-unneeded file on UNIX, using the ''rm'' command at the $ prompt. If you View a MIME-encoded message, Pine will ask whether to save it to a file with a name of your choice. Pine will decode the message and create the file in your home directory on UNIX. It can then be downloaded to your PC using kermit. MIME-encoded files are often binaries rather than plain text, so you should set kermit to transfer a binary file. UPLOADING FROM THE PC TO PINE Send email in plain text if possible. Save the document as plain ASCII text with the PC application that created it. Use Kermit to upload it to UNIX. Run Pine, choose letter C, Compose, and address your message as usual. Move the cursor to the Message Text area and choose control-R, Read File, and type the name the file (the copy on UNIX) to insert. You will see the file on screen, as if you had typed it. If it looks strange, it's not plain text, so start over. After you finish, remember to remove the now-unneeded file on UNIX, using the ''rm'' command at the $ prompt. If you want to send a PC document, use Kermit to upload it, setting Kermit to transfer a binary file. Run Pine, choose letter C, Compose, and at the Attchmnt: header, type the name of the file (the copy on UNIX). Pine will encode it using MIME, and attach it to the end of any text you choose to type in the message. *Note*: with MIME or any form of encoding, you should determine whether the recipient of your message will be able to decode it. Plain text email (previous paragraph) can be read on any email system. ------------------------------------------------------------------------------- 19 HOW DO I GET A SESSION LOG WITHOUT ALL THE EMBEDDED ESCAPE SEQUENCES? This can be done in Kermit versions that have true terminal emulators, such as MS-DOS Kermit and Kermit 95. In MS-DOS Kermit: - Don't LOG SESSION. Instead, SET PRINTER <filename>. - Use Ctrl-Print Screen to "toggle" logging. In Kermit 95: - Don't LOG SESSION. Instead, SET PRINTER <filename>. - Assign the Kverb \KprtAuto to the key of your choice, e.g. "set key \315 \KprtAuto" to assign it to F1. - Use this key to toggle logging. The resulting file will contain only screen lines, and not the escape sequences that put them there. The mechanism used internally is called "autoprint", and works by sending each screen line to the printer or printer file when the cursor leaves it. In UNIX and OS-9 C-Kermit, you can "set session log text". This does not filter out escape sequences, but at least it takes care of CR/LF/CRLF conversion for you; see the description of this command in "Using C-Kermit". ------------------------------------------------------------------------------- 20 KERMIT DOESN'T WORK RIGHT WITH MY (RPI) ERROR-CORRECTING MODEM! When you buy a modern error-correcting, data-compressing, speed-buffering modem, you probably expect the modem to perform those functions, and most do. Unfortunately, some modems that claim to have these features do not have them at all, but require external software that implements them in your computer, rather than in the modem where they belong. The most widespread example of this practice is the Rockwell Protocol Interface (RPI), a proprietary "standard" from Rockwell International Company that allows modem companies to sell modems at a lower price by incorporating Rockwell chips that do not include error-correction or compression capabilities. This "standard" must be licensed from Rockwell, hence you will only find it implemented in commercial software, such as on the diskette (if any) that came with your modem. In general, such software is available only for PCs running Microsoft Windows 3.x or Windows 95, or built into proprietary communications packages like Comit. If your modem documentation says it requires "RPI-compatible" software for error correction and compression, and you want to use it with Kermit, then you are out of luck unless you also have the software driver for the modem and can use it on your computer. Otherwise you bought the wrong modem. Hopefully, you can return it. It is usually hard to tell by reading the modem box. One user reports: "The RPI bit is hidden on the back of the box: '*Error Control* V.42 and MNP RPI software,' and '*Data Compression* V.42bis RPI software.' The box design is such that, unless you happen to already know what RPI is, you think you're getting a modem with MNP/V.42 LAPM/V.42bis compression built in." If you can't return the modem, you can still use it without error correction, but then: - Noise is not filtered out on the modem-to-modem connection, as it would be with a real error-correcting modem, and noise bursts will interfere with your online sessions and your file transfers. - There is no modem-to-modem compression, because that requires error correction. - There is no flow control, because that too requires an error-correction protocol between the modems. - Speed buffering is ineffective because that requires flow control between the modems. Thus, if the two modems have different interface speeds, vast amounts of data will be lost. Thus, none of the modem's "advanced features" are really there. Why RPI is a bad idea: - Implementation of MNP, V.42, and V.42bis in software is a VERY big job. Since it is uneconomical for software companies to write software for any platform other than Microsoft Windows, it is unlikely that RPI drivers will ever be written for DOS, UNIX, OS/2, VMS, or any other platform. - Even when a company wants to produce a driver for (say) a new release of Windows, there is generally a long lag time before it is available. Thus you might find when you install your brand-new operating system that your modem has become useless. (NOTE: Windows 95 will change its driver specifications soon, probably in mid-1997, at which time all existing "WinRPI" drivers -- as well as drivers for the other types of controllerless modems -- will stop working.) - The driver software slows down your computer by consuming a vast amount of CPU cycles over and above what would be used if error-correction and compression were done in the modem, and it increases memory requirements, swapping, and in general can be expected to drag down the performance of your PC. - RPI seeks to replace an open communication method (the one that is universally used by serial communication software) by a closed, proprietary, licensed one, and potentially hold hostage all communications software developers to nondisclosure agreements. - It precludes publication of source code. - Since MNP 2-5 and V.42 and V.42bis are complex protocols, the software implementations will inevitably be buggy and are unlikely to be consistent, especially since the "standard" is not an open one, and the implementations themselves will not be open. - Even if the drivers are not buggy, the underlying operating system is likely to be. - Since not all software in the world will be "upgraded" to "support" the RPI "standard", your modem will not be usable in many of the ways you might have expected to use it. - Many people will buy these modems under the mistaken impression that they can use their high speeds and advanced features with their favorite software. The average mass-market consumer is unlikely to understand the implications of "requires RPI-compliant software" in tiny print on the box. - By Gresham's Law, "The bad drives out the good". RPI modems are cheaper, and might well drive reputable modems out of the marketplace, leaving the entire world's online community with no modems left to choose from but ones that will work only with Windows. This drives another nail into the coffin of "legacy" non-Windows platforms, and this, in turn, leaves the public with fewer choices for operating systems, applications, and computers themselves. What are the benefits of RPI? - Lower-cost modems? In order to save a few dollars, you are giving up the ability to use the modem on the platform of your choice, with the software of your choice, and you are probably going to get poorer performance than you would have had with the EC and DC protocols built-in over the life of the modem. How do I tell if I have an RPI modem? - According to Rockwell, all RPI modems should issue a message containing "RPI" in response to the command ATI3. Here are some examples: AFEP-V1.510-BP39 ROCKWELL RPI (TM) MODEM AFEP-V1.620z1.00 BS39 ROCKWELL RPI (TM) MODEM V1.620-BP39 ROCKWELL RPI (TM) MODEM - The command to enable error correction (such as AT&Q5, depends on the modem) results in an ERROR response. - They normally have AT+Hdigit commands to control the RPI interface. (This one is not dependable, since there are no standards for modem commands, and so AT+H might be used on non-RPI modems for some entirely unrelated purpose.) Is there a list of RPI modems? - No. Just about any modem manufacturer is likely to have RPI models. The modem market is incredibly volatile, fast-moving, and voracious. Any such list would be obsolete before you could see it. Once-scrupulous companies will now do anything to cut costs and increase margins. They have no choice -- if your competitors are doing it, you have to do it too or lose your business. Rockwell licenses RPI "technology" to anyone who will pay for it, but is under no obligation to disclose its licensees, nor are the licensees under any obligation to inform Rockwell (or anybody else) which models contain RPI chips and which do not. In many cases, the same make and model can have RPI and non-RPI variations. This makes technical support an increasingly difficult job. By saving a small amount of money for themselves, the modem manufacturers have created unneeded confusion among users and service providers, and driven up costs throughout the online world. Is RPI the only "software driven" modem scheme? - No. There are similar products from other companies. This further complicates the task of the help desks of the world, for even once they have ruled out that a modem problem is due to RPI, it might be some other kind of "controllerless" modem based, for example, on the HSM chipset from AT&T (now Lucent). US Robotics now sells a "Winmodem" (see next question). We can only expect to see more and more of this in the future. As a maker of such items commented in the comp.dcom.modems newsgroup, "There's certainly a market for platform-independent modems, but you can't expect manufacturers to ignore the market opportunity for Windows-only modems, especially when they can have a cost and performance advantage." Of course you can't. But what about end users who don't understand any of this? Most of them do not make informed choices when buying modems. And increasingly, many of them make no choice at all -- the modem comes preinstalled in a PC they have bought, and does not even include a manual; sometimes not even a brand name. And now that RPI modems have been out for a while, we are beginning to see how they are passed from hand to hand, installed in or connected to new computers (for use, e.g., with DOS or Linux) and causing a whole new wave of problems. If you have an RPI or other controllerless modem, and you need to use it in a setting for which a driver is not available -- that is, in most cases, any platform other than a PC running Microsoft Windows -- you are just plain out of luck. Return it and buy a real modem. This way, you will encourage modem manufacturers to continue to make real "platform-independent" modems. To re-emphasize one of the worst aspects of these modems, here is independent commentary from the comp.dcom.modems newsgroup, 14 Nov 96: "If you don't plan to run [Windows 95], or more precisely, if you don't want to run just versions of Windows '95 released between the initial launch and next summer, then this modem may not be usable at all. "Microsoft plans to change the driver interface in the near future and you will need to get new drivers from somebody. This isn't a secret or anything; it's part of the gradual merging of '95 and NT and they want a common driver for both starting real soon. When this happens and you want to upgrade your OS, you have to hope that your vendor will continue to support the model of modem you bought and release new drivers. Those of you who get one of these modems in a PC will have to fight with the PC maker and the modem maker when you try to change (or upgrade) the OS on your PC. "If your vendor makes new drivers available for the operating systems you want to use for older models of their modems, you have no problem. If they won't support last years modems at all, then you have a problem. "Yet another reason to not buy modems with detached brains. "It's like the Monty Python "New Brain" sketch. You really should pay the extra $30 for a whole real brain in your modem. :-)" (End quote) ------------------------------------------------------------------------------- 21 WHAT ABOUT WINMODEMS? Refer to the previous section. Note, however, that Winmodems are even more Windows-dependent than RPI modems, as they rely on the Windows drivers not only for error correction and data compression, but for all of their modem functions. Thus they are totally useless outside of Windows 3.1 or Windows 95, and even under those operating systems, they can be used only by native Windows applications, and not by DOS applications -- not even when they are running in a Windows window. To quote from a posting to comp.dcom.modems from August 7, 1996: "While the Winmodem does have some advantages over modems, this device and others like it are generally inferior to a real and true modem. The Winmodem isn't really a modem, it's just a DSP and a few other componants on a card. It doesn't become a modem until you load up the Windows drivers for it. First off this means that you're totally and completely stuck with Windows software. No support for DOS in any way (not even through a DOS session in Windows), OS/2, Linux, or even WinNT. Furthermore it uses your computer CPU for some tasks normally handled by a processor in the modem. This drains some CPU power and memory from your computer, which can slow applications down (although just how much it'll slow things down depends on a number of factors)." Thus you can not use MS-DOS Kermit with a Winmodem. You can, however, use Kermit 95 in Windows 95 (not Windows NT) with a Winmodem; in this case you can treat it as a Sportster. ------------------------------------------------------------------------------- 22 WHAT KIND OF MODEM SHOULD I BUY? Refer to the previous two sections. We have always recommended external modems. In the past, the principle reasons for this were that: - They can be connected to any kind of computer that has a serial port. - You can monitor the lights for troubleshooting. - They don't cause interrupt conflicts or address confusion, as internal modems almost always do. In recent times, the reasons to stick with external modems are all the more compelling: - Almost any recent-model modem is bound to have bugs and defects. Therefore it is better to keep them outside of your PC, where they can't affect the internal bus, configuration, or interrupt structure of your computer. - External modems are almost never "controllerless". To the best of our knowledge, all RPI modems, Winmodems, etc, are internal PC modems. - External modems are never "Plug and Play". Plug and Play modems, to the best of our knowledge, work only in Windows 95, and need special OS-specific loaders to be initialized correctly. They can't be used with DOS applications, even in a Windows 95 DOS window. We do not recommend or endorse any particular brand of modem. However, we do recommend the following attributes: - It should be external rather than internal. The extra price is worth it. - It should follow established ITU-T (formerly CCITT) standards like V.32bis, V.34, V.42, and V.42bis. If it claims to "exceed" standards or "set" standards, beware; it is unlikely to interoperate correctly, or at all, with modems from other manufacturers. - It must not depend on operating-system-specific drivers or loaders for any of its modulation, error-correction, or compression functions. The operating system should be able to make full use of it through its serial-port driver, with the application providing the interface to the modem's command language. Thus you should be able to change or upgrade operating systems without losing the ability to use your modem. Read the box carefully before buying. ------------------------------------------------------------------------------- 23 MY ARROW KEYS DON'T WORK Newsgroups: comp.protocols.kermit.misc Date: Mon Apr 24 10:24:29 1995 From: Frank da Cruz <fdc@columbia.edu> Subject: Re: arrow keys and www? Organization: Columbia University In article <3n2s56$rb4@news-2.csn.net>, Gideon Weisz <gweisz@csn.net> wrote: > > This has to be a very simple problem, so apologies in advance, but I > am stuck. In www, using lynx, with mskermit 3.14 and vt220 (and > HEBREW macro) the arrow keys do not work right. To move among > highlighted links, one is supposed to use the up/down arrows and to > move among levels the left/right keys. However, if I use > right-arrow, I get "do you wish to send a comment"; if I use > left-arrow it is taken as a command to download down-arrow moves me > up! (up the screen to the last highlight). > Kermit is emulating a real VT220 terminal. The VT220 cursor (arrow) keypad can be in one of two modes: cursor mode and application mode. These keys send different escape sequences depending on which mode they are in. When a VT220 is turned on (and when Kermit is started), the arrow keys are in cursor mode. By default (that is, unless you give SET KEY commands to change things), MS-DOS Kermit uses the IBM keyboard arrow keys as the VT220 arrow keys. Each key has a "verb" assigned to it: Up arrow \Kuparr Down arrow \Kdnarr Right arrow \Krtarr Left arrow \Klfarr These verbs track the cursor keypad mode automatically, and send the following escape sequences: Cursor Mode Application Mode \Kuparr CSI A SS3 A \Kdnarr CSI B SS3 B \Krtarr CSI C SS3 C \Klfarr CSI D SS3 D where CSI is ESC followed by left bracket ([) on a 7-bit connection or decimal 155 on an 8-bit connection, and SS3 is ESC followed by O (uppercase letter O) on a 7-bit connection and decimal 143 on an 8-bit connection. How does the cursor keypad mode change? The host can change it by sending special escape sequences, or you can change it yourself by using the command: SET TERMINAL ARROW-KEYS { CURSOR, APPLICATION } So why do the arrow keys not work in Lynx? Or, in general, in any particular application: 1. Because the application expects the keypad to be in one mode when it is in the other mode. This is a deficiency on the part of the application. Applications should never ASSUME which mode the cursor keypad is in, but rather, they should PUT the keypad in the desired mode, or else they should accept arrow-key codes from either mode. Workaround: tell Kermit to SET TERM ARROW CURSOR (or APPLICATION). 2. Because of a terminal-type mismatch. Lynx, in particular, does not seem to use the termcap database (it uses only terminfo), and so therefore might not understand Kermit's VT220 or VT320 terminal type (this kind of confusion typically occurs when a terminal type is in the termcap database but not the terminfo one, and therefore works with EMACS or vi, but not with Lynx). Solution: tell Kermit to SET TERM TYPE VT100 and also tell the host your terminal type is VT100, before starting Lynx, and ask you system administrator to add missing terminfo entries. 3. Because of a character-size mismatch. If you have been using a VMS-based VT220 or VT320 fullscreen application (such as ALEPH, EVE, etc), you might find that your arrow keys are sending 8-bit codes rather than 7-bit codes, and then when switching to another application like Lynx, the new application might not understand the 8-bit codes. Again, this is a deficiency of the application. Workaround: tell Kermit to SET TERM CONTROLS 7. I put MS-DOS Kermit into Hebrew mode, accessed the ALEPH software, tried the arrow keys and they worked OK. Then I left ALEPH and started Lynx and got the same symptoms you reported. The three steps above fixed the problem. - Frank ------------------------------------------------------------------------------- 24 KERMIT UNDER WINDOWS CAN'T FIND MY PORT Q: We use Kermit 3.14 very heavily on our campus. From DOS everything works great. From MS-Windows, however, sometimes it works but often our users will get a message like: unknown hardware for port, using BIOS... or: cannot use RTS/CTS on non-UART port A: First, let's assume that your COM port is not, in fact, an internal "controllerless" modem, such as a Winmodem or RPI modem -- you can't use these with MS-DOS Kermit or, for that matter, with any non-Windows application or in any operating system other than Microsoft Windows. See the section on RPI modems for more information about this. Windows and/or Windows communications programs tamper with the PC BIOS, where Kermit goes to find out what ports are available and what their addresses (and IRQs) are. The solution to this problem is to supply this information to Kermit yourself. Here is a macro you can use to set your port under Windows. MS-DOS Kermit 3.14 is required. define PORT - if not = \v(argc) 2 end 1 Port number required, - if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, - end 1 \%1 - bad port number, - :PORT1, set com1 \x03f8 4, set port 1, end \v(status), - :PORT2, set com2 \x02f8 3, set port 2, end \v(status), - :PORT3, set com3 \x03e8 4, set port 3, end \v(status), - :PORT4, set com4 \x02e8 3, set port 4, end \v(status) Put this macro definition in your MSCUSTOM.INI file and then just tell Kermit "port 1", "port 2", "port 3", or "port 4" instead of "set port 1", etc, and everything should work as expected. IMPORTANT: The addresses and IRQs are the most common ones, but they are not going to work on every machine. PS/2s have different addresses and IRQs for COM3 and COM4. Many add-on cards -- especially internal modems -- might use different IRQs altogether, like 5. Again, see KERMIT.BWR for the gruesome details. Another user found that the following PORT macro also worked satisfactorily: define PORT - if not = \v(argc) 2 end 1 Port number required, - if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, - end 1 \%1 - bad port number, - :PORT1, run {MODE COM1:19,N,8,1}, set port 1, end \v(status), - :PORT2, run {MODE COM2:19,N,8,1}, set port 2, end \v(status), - :PORT3, run {MODE COM3:19,N,8,1}, set port 3, end \v(status), - :PORT4, run {MODE COM4:19,N,8,1}, set port 4, end \v(status) ------------------------------------------------------------------------------- 25 IF I HAVE AN ERROR CORRECTING MODEM WHY DO I NEED KERMIT PROTOCOL? "If modern modems are capable of hardware error correction and compression, isn't it redundant and inefficient to continue to use file-transfer protocols like Kermit and ZMODEM that provide the same services?" This is a common misconception, and, unfortunately, one that is promoted by many of the modem makers themselves (e.g. when you read about protocols in the modem manuals). The modem makers (some of them) might excel at what they do, but they are generally not experts on computers and software. For example, the following appears in a current modem manual: Generally, the most efficient file-transfer operations are achieved when the EC modem does the error checking in hardware, and the file-transfer protocol does not duplicate this effort. The YMODEM-G file-transfer protocol provides this level of service. This protocol was written for use with high-speed, error-control modems. This protocol does not provide any error-detection or recovery capability. But it is not true that protocols like YMODEM-g (or, as is often suggested by newcomers to modem communication, no protocol at all) are the best to use with error-correcting modems. That's because errors can also occur (and often do) outside the modem-to-modem connection. The most common causes are lack of sufficiently effective DCE/DTE flow control and resulting buffer overflows in the receiver; unbuffered UARTs that can't be serviced fast enough by a busy or slow CPU; interrupt conflicts (including characters lost due to having interrupts turned off by other drivers, e.g. disk-caching programs), and on and on -- things that are beyond the modem's control. Second, you don't always know that your error-correcting modem will make a successful MNP or V.42 connection with the other modem. The two modems might have mismatched capabilities or there might be a "failure to negotiate" the capabilities they do have. Would you want to use different file transfer methods depending on the type of connection negotiated by the modems? Not a good use of your time. Third, the communication channel outside the modems might not be fully transparent. For example, it might chop off the 8th bit of each byte, or it might filter out certain characters, or use them for special purposes rather than treating them as data. This is common with terminal servers and other types of communications front ends. Fast protocols like Zmodem and modern Kermit impose little additional overhead, and that small amount of overhead is well worth the savings in failed transfers, which are inevitable when using non-recovering methods in situations like the ones described above. But even more fundamentally: you can't know in advance that there will be no errors. So using a file transfer procedure without error recovery is silly, because if there are errors, you'll have to start all over again. It's like not buying fire insurance for your house because you think it is fireproof. Finally, what happens when the connection is broken? Say, after transferring 99 megabytes of a 100-megabyte file? Error-correcting modems can't stop wires from being cut or pulled out, nor can they prevent power failures or keep computers or applications from crashing. So again, you need a good error recovery protocol. Both Zmodem and Kermit can pick an interrupted transfer up from the point of failure. ------------------------------------------------------------------------------- 26 HOW DO I USE 'SET KEY' WITH PC F-KEYS, ETC, IN UNIX OR VMS C-KERMIT? The C-Kermit versions for UNIX, VMS, and so on, that do not have direct access to the keyboard and screen, and rely on your console driver, terminal window, external terminal emulator (such as MS-DOS Kermit), or actual terminal to perform the terminal functions. UNIX is an interesting case. Traditionally, UNIX was accessed through a terminal that was plugged into a terminal port on a timesharing system. Thus, there is no keyboard and screen -- just a communication port. In recent years, this type of access has been largely replaced by terminal servers, but there is still no keyboard and screen. However, now that we have a plethora of PC-based UNIX varieties that run on workstations (PCs) that actually do have a keyboard and screen, it would seem to make sense that Kermit should be able to see all the keys. Unfortunately, this is not the case. Most varieties of UNIX do not let the application see the keyboard. There is no kernel function called "get keyboard scan code". There is only read(), and read() reads a character, not a multibyte scan code. Thus, even if your console driver has programmed (say) your F1 key to send (say) ESC O P, Kermit will read three characters in succession, as if they were three keystrokes, not one. It has no way of knowing that you pressed the F1 key. As far Kermit knows, you pressed the Esc key, then the O key, then the P key. Now perhaps Linux *does* have a system call to let an application at the keyboard. But... - In what contexts does it work? Only on the raw console? In an xterm window? etc etc. - Does it require special privilege to execute? - What about all the other versions of UNIX that run on PCs -- FreeBSD, SCO, Solaris/Intel, etc etc? - What about all the other versions of UNIX that run on non-PC workstations -- SunOS, Solaris/Sparc, HP-UX, AIX, SGI, etc? So the answer is, for now at least -- and as the documentation states -- C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only for keys that generate a single 8-bit value, 0..255. Other types of mappings will have to be accomplished outside of Kermit by configuring your console driver, your xterm (e.g. with Xmodmap), and so on. ------------------------------------------------------------------------------- 27 HOW CAN I EXIT FROM C-KERMIT WITHOUT HANGING UP? Many people want to be able to make a dialout connection with UNIX C-Kermit, but then use some other software on the connection that C-Kermit made. For example, they want to use C-Kermit as their SLIP or PPP dialer. But they quickly find that when they exit from C-Kermit, that the connection is gone before they can start the other application. It is a fundamental property of UNIX (and VMS, and Windows 95 and NT, and most other modern operating systems) that when a process exits, then every file that was opened by that process is automatically closed by the operating system. In most cases, closing a terminal device (such as a dialout serial port) hangs up the modem (by turning off the DTR signal). There is nothing the process can do about it. However, many workarounds are possible. Here are just a few: - If your Kermit version supports the REDIRECT command, use it to start the desired application (e.g. "redirect pppd"). Read about the REDIRECT command in the second edition of Using C-Kermit. - Tell C-Kermit to SET MODEM HANGUP-METHOD RS232, and then configure your modem to ignore DTR (not recommended). - Find out the file descriptor of the open device (it is given by C-Kermit's \v(ttyfd) variable) and then run ("!") your other program from the C-Kermit prompt, feeding it the file descriptor, e.g. through shell redirection or a command line option (the method depends on the other program, the capabilities of the shell, etc). - After Kermit makes the connection, type "show comm" to find out the filename of the lock file. Then suspend Kermit, delete the lock file, then start the other program and tell it to open the same tty device. Note that you can also tell C-Kermit to use a communications file descriptor created by another process; see the command-line options list in "Using C-Kermit", 2nd edition. ------------------------------------------------------------------------------- 28 WHAT IS SUPERKERMIT? When the Kermit protocol was first developed in 1981, it had short packets and did not use sliding windows, but the design was deliberately extensible to allow for the addition of these and many other features later. A couple years later, when we defined the protocol for long packets and sliding windows, somebody somewhere started calling it "SuperKermit". Really, there's no such thing -- Kermit is Kermit. It's an extensible protocol in which the two file transfer partners negotiate automatically about what features they have in common and agree to use them. All modern Columbia Kermits support long packets and sliding windows (except IBM Mainframe Kermit does not "do windows" because it exists only in a half-duplex environment, whereas full duplex connections are needed for sliding windows). They also support compression, single and locking shifts (for moving 8-bit data efficiently through 7-bit communication channels), file-transfer recovery, dynamic packet lengths and timeouts, and all sorts of other advanced and serious features that whoever coined the term "SuperKermit" never dreamed about. Usually when BBSs or non-Columbia communication programs refer to "SuperKermit" they mean a 1985-vintage implementation of the Kermit protocol that implements a primitive and not very robust form of sliding windows, usually not in combination with long packets. However, if it is properly implemented, it should interoperate successfully with any other Kermit implementation, no matter how advanced or how minimal. That's the whole point of Kermit protocol. ------------------------------------------------------------------------------- 29 IS KERMIT SOFTWARE YEAR-2000 COMPLIANT? Kermit software is not, for the most part, date dependent. It makes connections, performs terminal emulation (in those versions that include this feature), transfers files, translates character sets, and, in most cases, executes scripts regardless of the date. "Year 2000 compliance" depends on the Kermit program and the underlying platform. If the operating system, file system, BIOS, hardware, and/or other critical component is not ready for the year 2000, then most likely Kermit isn't either, since it relies on the underlying OS and hardware for date / time service. The primary relevance of this question to Kermit software is whether post-millenium file dates are recognized, transmitted, received, and reproduced correctly during the file transfer process. This consideration, in turn, applies only to those Kermit versions that implement the optional "Attribute Packet" feature. These include C-Kermit, Kermit 95, MS-DOS Kermit, Kermit-370, and PDP-11 Kermit. If post-millenium dates are not processed correctly, file transfer will still take place, but the creation or modification date of the received file might be incorrect. The only exception would be if the "file collision update" feature is being used to prevent unnecessary transfer of files that have not changed since the last time a transfer took place; in this case, a file might be transferred unnecessarily, or it might not be transferred when it should have been. Correct operation of the update feature depends on both Kermit programs having the correct date and time. Of secondary importance are the time stamps in the transaction and/or debug logs, and the date-related script programming constructs, such as \v(date), \v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time) and \v(ntime), insofar as they might be affected by the date. Note: the aforementioned script programming constructs are available only in C-Kermit, Kermit 95, and MS-DOS Kermit. The \v(ndate) is a numeric-format date of the form yyyymmdd, suitable for comparison and sorting: e.g. 19970208 or 20011231. If the underlying operating system returns the correct date information, these variables will have the proper values. If not, then scripts that make decisions based on these variables might not operate correctly. Here is the current situation for the most popular Kermit software products. The minimum version known to be Year-2000 compliant is shown. We make no claims whatsoever about the underlying operating systems or file systems. The situation with Kermit programs not listed here is at present unknown. MS-DOS: MS-DOS Kermit: Version 3.15 or later required. Windows 3.1: MS-DOS Kermit: Version 3.15 or later required. Windows 95: Kermit 95: Version 1.1.3 or later required. Windows NT: Kermit 95: Version 1.1.3 or later required. OS/2: Kermit 95: Version 1.1.11 or later required. UNIX: C-Kermit: Version 6.0.192 or later required. VMS: C-Kermit: Yes, all versions. Kermit-32: unknown; Kermit-32 has not been supported since about 1987. Stratus VOS C-Kermit: Version 6.0.192 or later and VOS 12.3 or later required. VM/CMS: CMS Version 13 and Kermit-370 Version 4.3.2 or later required. Note: 4.3.2 is not formally released yet, but the patch up to this version is included as an optional "new update" file with the current release, 4.3.1. MVS/TSO: Kermit-370 for TSO: Version 4.3.2 or later required. MVS/ROSCOE: Kermit-370 for ROSCOE: Version 4.3.2 or later required. MUSIC: Kermit-370 for MUSIC: Version 4.3.0 or later required. CICS: Kermit-370 for CICS: Version 4.3.0 or later required. RT-11: KRT for RT-11 and TSX+: Version 3.63 or later required. RSTS/E: KRT for RSTS/E: Version 3.63 or later required. ------------------------------------------------------------------------------- 30 IS THERE A KERMIT LIBRARY? No, the Kermit Project does not supply an OLE or OLE-2 interface, a Kermit library, DLL, VBX, OCX, Active X control, Delphi component, or other type of Kermit module designed purely for embedding in other applications. We recommend that those who wish to embed communications functions -- connection establishment, logging in and other dialogs, file management, data transfer -- do so by invoking an existing Kermit program -- MS-DOS Kermit for DOS or Windows 3.x, Kermit 95 for Windows 95 or NT or OS/2, C-Kermit for UNIX or VMS, etc -- from within their application by a combination of command-line arguments and command files (Kermit script programs). If you have trouble with this, ask us for assistance. And of course, if you are providing this application to customers or clients, you must license the Kermit software from the Kermit Project. ------------------------------------------------------------------------------- 31 HOW DO I CALL UP A DIALBACK SERVICE? A dialback service is one which you dial up to, provide some kind of identification and/or authentication, such as a name and/or password, and then it looks up your phone number in a database and calls you back. It is a type of security, based on having the phone numbers of all authorized callers, and opening sessions for them only when they are calling from those numbers. Suppose you were using a Hayes modem to make a call to a dialback service. You would do the following: ATD7654321 (Dial the number) CONNECT 14400 (Read the response) Here you would have the identification / authentication dialog. Now the dialback service hangs up on you, and you must put the modem in answer mode: NO CARRIER (The connection is closed) ATS0=1 (Tell the modem to answer the next call) When the call comes in, the modem answers and you're on line. But now you want to automate the process. This is easily accomplished in Kermit. Let's use C-Kermit 6.0 to illustrate, since it has a new ANSWER command. Here is a simple script to do the job: set modem type usr ; or whatever set port /dev/cua ; or whatever set speed 38400 ; or whatever dial 7654321 ; dial the number if fail stop At this point, you would use INPUT and OUTPUT commands to accomplish the identification / authentication dialog. For example, if the dialback server prompts you with USERNAME: and PASSWORD:, and your script had previously stored these values in the variables \%u and \%p, respectively: input 10 USERNAME: if fail stop 1 No username prompt output \%u\13 input 10 PASSWORD: if fail stop 1 No password prompt output \%p\13 Now you will need to hang up your end of the connection, and then wait for the phone to ring: hangup answer 120 if fail stop 1 No callback The ANSWER command conditions the modem for answering (ATS0=1 for Hayes and compatible modems) and then waits the given number of seconds (120 in this case) for the call to come in. At this point, if the script is still executing, you've got a connection. You can give a CONNECT command, or execute a login script, or whatever else you want to do. ------------------------------------------------------------------------------- 32 HOW DOES THE NUMERIC KEYPAD WORK? This discussion applies to MS-DOS Kermit. The situation with Kermit 95 is slightly different: In Kermit 95, the Num Lock key can be mapped directly and the PC numeric keypad is mapped to the VT terminal numberic keypad by default. MS-DOS Kermit reads scan codes from the PC BIOS (but if you are using Windows, then all sorts of software layers are inserted between Kermit and BIOS, so matters are somewhat more uncertain. The BIOS reports one scan code for a numeric keypad key when Num Lock is on, and a different code when Num Lock is off. All that MS-DOS Kermit is doing is reading the scan codes from (what it thinks is) the BIOS. To use the PC's numeric keypad as if it were a VT terminal's numeric keypad in MS-DOS Kermit, you must make the appropriate key assignments, since they are not made by default. By default, when Num Lock is not on, the keys have the same assignments as the gray keys which have the same label (e.g. Home, End, Left Arrow, etc), for the benefit of 88-key keyboards. To make the desired key assignments, you can use the VT300.INI file in the KEYBOARD subdirectory of the MS-DOS Kermit directory: take keyboard\vt300.ini The pertinent commands from this file are: set key \850 \kkp0 ; Keypad 0 (Numlock) Keypad 0 set key \338 \kkp0 ; Keypad 0 (Normal) Keypad 0 set key \847 \kkp1 ; Keypad 1 (Numlock) Keypad 1 set key \335 \kkp1 ; Keypad 1 (Normal) Keypad 1 set key \848 \kkp2 ; Keypad 2 (Numlock) Keypad 2 set key \336 \kkp2 ; Keypad 2 (Normal) Keypad 2 set key \849 \kkp3 ; Keypad 3 (Numlock) Keypad 3 set key \337 \kkp3 ; Keypad 3 (Normal) Keypad 3 set key \843 \kkp4 ; Keypad 4 (Numlock) Keypad 4 set key \331 \kkp4 ; Keypad 4 (Normal) Keypad 4 set key \844 \kkp5 ; Keypad 5 (Numlock) Keypad 5 set key \332 \kkp5 ; Keypad 5 (Normal) Keypad 5 set key \845 \kkp6 ; Keypad 6 (Numlock) Keypad 6 set key \333 \kkp6 ; Keypad 6 (Normal) Keypad 6 set key \839 \kkp7 ; Keypad 7 (Numlock) Keypad 7 set key \327 \kkp7 ; Keypad 7 (Normal) Keypad 7 set key \840 \kkp8 ; Keypad 8 (Numlock) Keypad 8 set key \328 \kkp8 ; Keypad 8 (normal) Keypad 8 set key \841 \kkp9 ; Keypad 9 (Numlock) Keypad 9 set key \329 \kkp9 ; Keypad 9 (Normal) Keypad 9 set key \334 \kkpminus ; Keypad + Keypad - set key \2382 \kkpcoma ; ALT Keypad + Keypad , set key \851 \kkpdot ; Keypad . (Numlock) Keypad . set key \339 \kkpdot ; Keypad . (normal) Keypad . set key \4365 \Kkpenter ; Keypad Enter Keypad Enter ; F1 PF1 (default Kermit) ; Use GOLD.COM to make Num Lock work as PF1/Gold. set key \325 \kPF1 ; This works with WPGGOLD.COM. set key \4399 \kPF2 ; Keypad / PF2 set key \311 \kPF3 ; Keypad * PF3 set key \330 \kPF4 ; Keypad - PF4 Key You need the GOLD TSR to make the Num Lock key work like the DEC Gold key. The GOLD TSR is found in the same directory as the VT300.INI file. The rest of the commands in the VT300.INI file set up the function keys and editing keys to be like the corresponding DEC VT220/320 keys. But there is still one more piece to the puzzle. As noted, the VT keypad can be in one of two modes: numeric or application. It is the responsibility of the host application to send an escape sequence to put the keypad into the appropriate mode before attempting to read keystrokes from it. But some applications fail to do that and simply ASSUME that the keypad is in the right mode. In many cases this assumption is wrong. So MS-DOS Kermit has a command that lets you force the keypad into the desired mode: SET TERMINAL KEYPAD { APPLICATION, NUMERIC } ------------------------------------------------------------------------------- 33 HOW TO GET RID OF THE "OK TO EXIT?" PROMPT? When I try to exit from Kermit it says: A serial connection might still be active on com2. OK to exit? But the connection is closed! How do I make this message and prompt go away? It prevents scripts from running unattended. Short answer: SET EXIT WARNING OFF Long answer: Kermit gives this message and prompt when given the EXIT command (explict or implied), or when told to change its communication device, and a connection appears to be active on the current one. On a serial device, this means that the Carrier Detect (CD) signal is still present. On a network connection, it means that Kermit has not closed the connection and it does not seem that Kermit's network partner has closed it either. If you are using a modem, the best course is to fix it (or the cable) so CD tracks the connection. Kermit generally tries to do this itself, but sometimes it is not possible due to switch settings in the modem. See your modem manual for details. In some cases, however, the underlying operating system or device driver does not provide Kermit with good information. If you can't fix the modem or cable to report the connection status properly, use SET EXIT WARNING OFF to tell Kermit to ignore the apparent connection status upon EXIT. ------------------------------------------------------------------------------- 34 HOW TO TELL KERMIT TO IGNORE DIALTONE? Sometimes the telephone being used to place a modem call does not present a dialtone that the modem recognizes. This usually happens with PBXs, ISDN phones, etc. But Kermit programs generally tell the modem to wait for dialtone before dialing. To find out how to get around this feature, you'll need to look at your modem manual. If it's a Hayes compatible (i.e. uses the AT command set), then it's probably a matter of changing the "X" value in the init string. Most Kermit init strings use X4, in order to get the widest possible selection of result codes. In many modems, X3 is used to select "blind dialing" (i.e. without waiting for dialtone), but this also sacrifices the ability to get a BUSY response, and therefore to redial automatically if the line is busy. Hopefully your modem has finer-grained selections. In C-Kermit or Kermit 95, a good way to change the X value in the init string is, after you set your modem type: set modem type xxxx set modem command init \freplace(\v(m_init),X4,X3) This assumes your modem type is "xxxx", and its init string contains X4. In MS-DOS Kermit, just edit the dialing script. ------------------------------------------------------------------------------- 35 WHERE IS THE DIALING SCRIPT FOR MY MODEM? C-Kermit and Kermit 95 do not use dialing scripts; their modem support is built in. To see a list of the modems supported, type: set modem type ? at the prompt. If your modem is not listed, then (a) maybe one of the other modem types will work ("generic-high-speed" is usually a good guess), and (b) you can install your own modem definition as described on pages 90-92 of Using C-Kermit; this, of course, requires knowledge of how to operate your modem, which comes from reading the manual (if any) that came with it. MS-DOS Kermit, on the other hand, uses dialing scripts, one per modem type. The ones we have are in the MODEMS subdirectory of your MS-DOS Kermit directory. If you don't see one there for your modem, it is easy to adapt one of the existing ones. Just use a text editor to change the modem-specific commands to the ones for your modem; consult your modem manual to find out what its commands are. In either case, if you have added support for a new modem, please send your new definitions or script back to us, along with a complete description of your modem's manufacturer, name, model designation, and features (modulation, error correction and compression protocols, etc), so we can make them available to others. ------------------------------------------------------------------------------- 36 I'M HAVING TERMINAL EMULATION PROBLEMS WITH C-KERMIT C-Kermit on UNIX, VMS, etc, does not perform terminal emulation at all; nobody ever claimed it did. Instead, it is a semitransparent (or, if you make it so) a fully transparent communications pipe between the remote computer or service and your local terminal, terminal emulator, terminal window, or console, which provides the terminal functions. Thus, it is similar to Telnet, cu, tip, "set host" in VMS, etc, but with added functionality (file transfer and management, character-set translation, scripting, etc). If you experience fractured screens, you probably have a mismatch between the type of terminal or emulator you are running C-Kermit and the type the remote host or service thinks you have. Solution: let the host know what type of terminal you really have. For example, in Linux it would be ANSI or SCOANSI. In an HPTERM window, it would be HPTERM. In an AIX window, it would be AIXTERM, etc. If your arrow and function keys don't work, then you must configure your terminal or emulator to have these keys send what the host or application expects them to send. The method for doing this depends on your terminal or emulator. For example, when using xterm or another X-based terminal window, use xmodmap to configure your keyboard. C-Kermit itself can't be used for this (even though it has a SET KEY command) because it can't "see" the special keys (arrow keys, function keys, editing keys, etc). If host-directed transparent printing doesn't work, this is a deficiency in your terminal or emulator and has nothing to do with Kermit. However, if you have the ability to change the host application, then you can use C-Kermit's autodownload and/or APC features to accomplish the same thing. See the manual for details. ------------------------------------------------------------------------------- 37 DIVIDE OVERFLOW IN MS-DOS KERMIT If you find that MS-DOS Kermit is giving you "Divide Overflow" errors after an OS or hardware upgrade, or on a new PC: - If your PC is running Windows 95, Windows NT, or OS/2, then you should run the 32-bit version of Kermit for those platforms Kermit 95. This is the only Kermit software that is recommended or supported for Windows 95, Windows NT, or OS/2. - If your PC is running DOS (MS-DOS, PC-DOS, DR-DOS, etc) as its base operating system (and perhaps Windows 3.x on top of that), then upgrade your version of MS-DOS Kermit to the current release, MS-DOS Kermit 3.15 ------------------------------------------------------------------------------- (End)